Skip to content

Use tcx.short_string() in more diagnostics #144039

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

estebank
Copy link
Contributor

TyCtxt::short_string ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use short_string.

We add support for shortening the path of "trait path only".

Every manual use of short_string is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).

@rustbot
Copy link
Collaborator

rustbot commented Jul 16, 2025

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 16, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 16, 2025

HIR ty lowering was modified

cc @fmease

Comment on lines 1 to 3
// FIXME(estebank): diagnostics with long type paths that don't print out the full path anywhere
// still prints the note explaining where the type was written to.
//@ compile-flags: -Zwrite-long-types-to-disk=yes
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found these by changing the default -Zwrite-long-types-to-disk=no in compiletest::runtest::TestCx::make_compile_args to yes, which highlighted some preexisting cases that I'll investigate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One left: tests/ui/methods/filter-relevant-fn-bounds.rs. Also pre-existing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Figured out what's happening on the last case standing: it's a consequence of using on_unimplemented. Given the way the machinery is set up, we have to create a map between the type parameter name of the annotated trait and the resolved type, which we need to shorten. Because this happens before we know which type parameters are even referenced in the annotation, we pessimize and write the types to disk when any of those params needs to be shortened, regardless of whether the corresponding message ever gets printed by the E0277. Changing this to use the full type, makes other diagnostics longer. The proper solution is to rearchitect on_unimplemented to make a map from type param to the actual type, and the shorten during rendering, instead of using strings throughout. I feel it's ok to leave that one case in the test suite be for now.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

Comment on lines -3336 to +3341
let ty_str = tcx.short_string(ty, err.long_ty_path());
let msg = format!("required because it appears within the type `{ty_str}`");
let mut msg = || {
let ty_str = tcx.short_string(ty, err.long_ty_path());
format!("required because it appears within the type `{ty_str}`")
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably illustrates a problem we have with the current system: we don't prevent if a short string was created but was never printed. I think there could be a mechanism (a drop guard for a custom short_string return newtype) in which we detect that. Could you open an issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These ui tests are now regressions because we should not "show generic arguments when the method can't be found in any implementations". If you're trying to prevent us from creating a short string when we don't use it, maybe we should pass a closure down instead of the ty_str_reported.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that I originally made the message only mention the item name instead of the Ty<'_> was precisely because we didn't have short_string back then and we could end up with quite long output accidentally. I was concerned back then that there are cases where the method is available on a given type depending on bounds on its type parameters, so I felt comfortable relying exclusively on short_string for keeping the output readable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#81576 says we shouldn't show generics at all if they are irrelevant. I agree. I think we should spend effort keeping that behavior here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be ok to display the type's identity (Option<T> instead of the current Option and this PR's Option<ElaboratedType>) or a freshened type (Option<_>)? I'd really want to keep the structured error's field a Ty<'_> instead of a String, and using the identity allows for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last commit does this

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

inconsistent output in aarch64

seems quite odd. Could you explain what the issue is?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was the error from #144039 (comment)

I suspect that that platform in particular prints a slightly different output for the closure type which puts it under the default terminal width threshold.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that platform in particular prints a slightly different output for the closure type

That is really really surprising for me. Could you post an issue for this? This seems very worthy of investigation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 21, 2025
@estebank estebank added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 23, 2025
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#81576 says we shouldn't show generics at all if they are irrelevant. I agree. I think we should spend effort keeping that behavior here.

@rustbot
Copy link
Collaborator

rustbot commented Jul 24, 2025

This PR modifies tests/ui/issues/. If this PR is adding new tests to tests/ui/issues/,
please refrain from doing so, and instead add it to more descriptive subdirectories.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 26, 2025
@estebank estebank added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 28, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 28, 2025

Some changes occurred in need_type_info.rs

cc @lcnr

@rust-log-analyzer

This comment has been minimized.

estebank added 2 commits July 29, 2025 15:46
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`.

We add support for shortening the path of "trait path only".

Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
When we don't actually print out a shortened type we don't need the "use `--verbose`" note.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants